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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 3 of the Ud interface between the Front-Ends (FEs) and the User Data 
Repository (UDR) in the User Data Convergence (UDC architecture). 

This 3GPP Technical Specification (TS) specifies the protocol and interactions between the FE and the UDR for Ud 
reference point, in particular: 

The details of the LDAP protocol that are to be considered 

The details of the SOAP envelope that provide support for subscriptions to notifications and notifications about 
data changes service (S/N operations). 

The User Data Convergence Stage 2 description (architecture and information flows) is specified in 3GPP TS 23.335 
[10]. 

Details related to the data model used with LDAP (e.g., directory tree) are left outside the scope of this specification. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TR 41.001: "GSM Release specifications". 

[3] 3GPP TR 21 912 (V3.1.0): "Example 2, using fixed text". 

[4] IETF RFC 4510: "Lightweight Directory Access Protocol (v3)". 

[5] IETF "LDAP Transactions" <draft-zeilenga-ldap-txn-15.txt>. 

[6] W3C Recommendation "Simple Object Access Protocol (SOAP) 1 .2" (27 April 2007). 

http : //www . w3 . org/TR/. 

[7] IETF RFC 2616 (June 1999): "Hypertext Transfer Protocol - HTTP/1.1". 

[8] IETF RFC 45 1 1 : "Lightweight Directory Access Protocol (LDAP): The Protocol". 

[9] IETF RFC 4528: "Lightweight Directory Access Protocol (LDAP) Assertion Control". 

[10] 3GPP TS 23.335: "User Data Convergence (UDC); Technical realization and information flows". 

[II] IETF RFC 4512: "Lightweight Directory Access Protocol (LDAP): Directory Information 
Models". 

[12]. 3GPP TS 32.182: "Telecommunication management; User Data Convergence (UDC); Common 

Baseline Information Model". 

[13] IETF RFC 793: "Transmission Control Protocol". 

[14] IETF RFC 2234: "Augmented BNF for Syntax Specifications: ABNF" . 
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[15] 3GPP TS 33.210: "3G Security; Network Domain Security; IP network layer security". 

[13] IETF RFC 4513: "Lightweight Directory Access Protocol (LDAP): Authentication Methods and 

Security Mechanisms". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

LDAP Session: starts with LDAP Bind Operation and ends with LDAP Unbind Operation or Notice of Disconnection. 

Front End: a core network functional entity or service layer entity or provisioning entity that can access user data 
stored in a unique repository. 

Front End Identifier: A name that uniquely identifies an FE within the set of all FEs accessing an UDR. 

Front End Cluster: FEs handling the same application may be grouped in clusters to differentiate between them e.g. 
with regard to geographical location, feature support, vendor, or other characteristics. All FEs within a cluster are 
treated equally for required purposes (e.g. authorization, notifications, etc.). 

Application type: The application handled by a FE (e.g. HLR) determines the appUcation type of the FE. The 
application type is derived from the name indicated by a FE. 

Front End Cluster Identifier: A name that identifies a cluster grouped with FEs supporting the same application. 

User Data Repository: facility where user data can be accessed stored and managed in a common way. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 
Ud reference point between a FE and the UDR 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 

FE Front End 

UDR User Data Repository 

NDS Network Domain Security 



Protocol Stack 



4.1 General 



Data access messages on the Ud interface shall make use of IETF RFC 4510 [4] and IETF RFC 4511 [8]. See section 
4.2 for details. 

Subscription messages and Notification messages on the Ud interface shall make use of SOAP [6]. See section 4.3 for 
details. 
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4.2 Protocol stack for Ud Data Access Messages 

Figure 4.2-1 shows the protocol layering used for UDR data access. 



LDAP 






LDAP 






TCP 


TCP 






IP 


IP 






L2 


L2 






L1 


L1 







FE 



Ud 



UDR 



Figure 4.2-1 Protocol Layering for Data Access 



4.3 Protocol Stack for Ud Subscriptions/Notifications 

Figure 4.3-1 shows the protocol layering used for Ud Subscription/Notification. 
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Figure 4.3-1 Protocol Layering for Subscription/Notification 



General Messages 



5.1 



General 



This section describes common messages for UDC to establish sessions and administrate transactions. For an existing 
session, UDC messages are exchanged between the FE and the UDR. See figure B.1-1 in Annex B for general LDAP 
message flows. 
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5.2 Open Link for a LDAP Session 



To initiate a LDAP session, a Front-End shall first establish a transport connection with the UDR. The transport 
connection shall be a TCP connection. The IP Layer may be secured according to section 8. When IPsec is used, an 
IPsec connection may support several TCP connections, each supporting a LDAP session. 

After establishment of the transport connection, the FE shall initiate a LDAP session by sending a LDAP BindRequest 
message. The establishment of the LDAP session shall comply with IETF RFC 45 11 [8] . It shall be done before sending 
any other LDAP message. FE Identifier or FE Cluster Identifier shall be included in the BindRequest message. 

The UDR shall support the "unauthenticated authentication mechanism of simple Bind" and the "name/password 
authentication mechanism of simple Bind" in the "simple authentication method" specified in IETF RFC 4513 [16]. 

The UDR derives the application type from the FE Identifier or the FE Cluster Identifier. If the FE provided the Front 
End Identifier the UDR may also derive the Front End Cluster Identifier. 

NOTE: As security is handled at IP Layer (see section 8), optional security mechanisms (TLS, SASL) described 
in IETF RFC 4513 [16] specification are not required for Ud. 

5.3 Close Link for a LDAP Session 

Termination of the LDAP session may be initiated by the FE by sending an UnbindRequest message or by the UDR by 
sending a Notice of Disconnection message. The termination of the LDAP session shall comply with IETF RFC 45 1 1 
[8] 

5.4 Transactions 

In order to allow FEs to relate a number of update operations, such as Create (see 6.3), Delete (see 6.4), and Update (see 
6.5), and have them performed in one unit of interaction, the transaction concept specified in IETF "LDAP Transactions 
<draft-zeilenga-ldap-txn-15.txt>" [5] shall be supported. See figure B.2-1 in Annex B for LDAP Transaction flows. 

If used, they shall only be used for a single subscriber in order to decrease the complexity of transactions. 

LDAP server shall terminate the transaction if the timer is expired. 



6 User Data Convergence IVIessages 

6.1 General 

The Query, Create, Delete and Update messages for UDC shall comply with IETF RFC 451 1 [8]. 

6.2 Query 

Query request messages shall be coded as LDAP SearchRequest messages. 

Query result messages shall be coded as LDAP SearchResultEntry, SearchResultReference, and SearchResultDone 

messages. 

6.3 Create 

Create request messages shall be coded as LDAP AddRequest messages or as LDAP ModifyRequest messages with the 
"operation" field set to "add", depending on the data to be created. 

Create result messages shall be coded as LDAP AddResponse messages or as LDAP ModifyResponse messages, 
depending on the used LDAP request message. 
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6.4 Delete 

Delete request messages shall be coded as LDAP DelRequest messages or as LDAP ModifyRequest messages with the 
"operation" field set to "delete", depending on the data to be deleted. 

Delete result messages shall be coded as LDAP DelResponse messages or as LDAP ModifyResponse messages, 
depending on the used LDAP request message. 

The LDAP assertion control as specified in IETF RFC 4528 [9] may be used for conditional delete operation if the FE 
knows that the UDR supports the corresponding control. 

6.5 Update 

Update request messages shall be coded as LDAP ModifyRequest messages with "operation" field set to "replace". 

Update result messages shall be coded as LDAP ModifyResponse messages. 

The LDAP assertion control as specified in IETF RFC 4528 [9] may be used for conditional update operation if the FE 
knows that the UDR supports the corresponding control. 

6.6 Subscribe 

Subscribe request messages shall make use of the HTTP Post method and contain a SOAP message envelope. 

Subscribe response messages shall be coded as HTTP response message and shall contain a SOAP envelope. 

Subscribe request and response messages shall contain a SOAP message envelope header with a header block 
containing the following elements: 

serviceName 

This optional element identifies a service in the Front End. The serviceName is stored in the UDR and is used 

when the Notify message is sent. The serviceName is of type string with up to 20 characters. 

msgid 

This element uniquely identifies the Subscribe message request - response pair within a connection. The msgId 
is of type integer. The FE shall allocate the value and use it together with the connid (if any) to correlate a 
received subscribe response with a sent subscribe request. 

- connid 

This optional element identifies the connection between FE and UDR. The connid is of type integer. If used, the 
value is allocated by the FE and is used together with the msgId to correlate a subscribe response with a 
subscribe request. 

An example of a SOAP envelope header for a Subscribe request message is given below: 

<env:Header> 

<hb: CorrelationHeader xmlns :hb="urn:headerblock" env:mustUnderstand="true"> 
<hb : serviceName>HLR-FE</hb : serviceName> 
<hb:msgld>2 54 9</hb:msgld> 
<hb: connId>2</hb : connId> 
</hb : CorrelationHeader> 
</env: Header > 

The UDR shall copy the SOAP Envelope Header received in the Subscribe request and send it unmodified in the 
Subscribe response. 

Subscribe request messages shall contain a SOAP message envelope body formatted according to the XML schema 
defined in Annex A. 

Subscribe response messages shall contain an empty SOAP message envelope body. Only the HTTP status code in the 
Subscribe response message is used to indicate success or failure. 
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6.7 Notify 

Notify request messages shall make use of the HTTP Post method and contain a SOAP message envelope. 

Notify response messages shall be coded as HTTP response message and shall contain a SOAP message envelope. 

Notify request and response messages shall contain a SOAP message envelope header with a header block containing 
the following elements: 

serviceName 

This optional element identifies a service in the Front End. The value is copied from the Subscribe message or 

pre-configured in the UDR. The serviceName is of type string with up to 20 characters. 

msgid 

This element uniquely identifies the Notify message request - response pair within a connection. The msgId is of 
type integer. The UDR shall allocate the value and use it together with the connid (if any) to correlate a received 
notify response with a sent notify request. 

connid 

This optional element identifies the connection between UDR and FE. The connid is of type integer. If used, the 

value is allocated by the UDR and is used together with the msgId to correlate a notify response with a notify 

request. 

An example of a SOAP envelope header for a Notify request message is given below: 

<env:Header> 

<hb: CorrelationHeader xmlns :hb="urn:headerblock" env:mustUnderstand="true"> 
<hb : serviceName>HLR-FE</hb : serviceName> 
<hb:msgld>78 762 73 5 0</hb:msgld> 
<hb : connId>l</hb : connId> 
</hb : CorrelationHeader> 
</env: Header > 

Application Front Ends shall copy the SOAP Envelope Header received in the Notify request and send it unmodified in 
the Notify response. 

Notify request messages shall contain a SOAP message envelope body formatted according to the XML schema defined 
in Annex A. 

Notify response messages shall contain an empty SOAP message envelope body. Only the HTTP status code in the 
Notify response message is used to indicate success or failure. 



6.8 Abandon operation 



When a FE wishes to abandon an uncompleted operation towards the UDR, it shall send a LDAP AbandonRequest 

message. 



7 Information Elements 

7.1 Information Element Types with LDAP 

Information elements and their type to be used in the messages on a given Ud interface for the LDAP Search, Add, 
Delete and Modify operations are dependent of the application type of the Ud interface. They are described in a LDAP 
Directory Schema associated to this application type. The general content and structure of a LDAP Directory Schema is 
described in IETF RFC 4512 [1 1]. 

NOTE: The LDAP Directory Schema associated to an application type relates to the application data view 
mentioned in 3GPP TS 23.335 [10]. 
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When Information elements that are used on a given Ud interface are addressed in 3GPP TS 32.182 [12], their 
description in the LD AP Directory Schema associated to the application type of this Ud interface shall comply with 
3GPPTS 32.182 [12]. 

7.2 Information Elements for Subscriptions and Notifications 

Information elements and their type to be used for subscriptions and notifications about data changes shall also follow 
the rules specified above in 7.1 and according to the formats/schemas defined in Annex A. 



8 Security 

Ud interface provides security, as needed, by security methods defined in 3GPP TS 33.210 [15] 

Application sensitive data (e.g. permanent authentication keys) shall be stored encrypted in the UDR and transferred 
encrypted over Ud. 

Editor"s note: statement above must be reviewed and confirmed by SA3 



ETSI 



3GPP TS 29.335 version 9.0.0 Release 9 1 2 ETSI TS 1 29 335 V9.0.0 (201 0-04) 

Annex A (normative): SOAP Subscription and Notification 
A.1 XIVIL schema for Subscribe Request 

<?xml version="l .0" encoding="UTF-8 "?> 
<xs : schema xmlns= "http : //www . 3gpp . org/subscription" 
xmlns :xs="http : //www.w3 . org/2 001/XMLSchema" 

targetNamespace="http : //www. 3gpp .org/udc/ subscript ion" elementFormDefault=" qualified" > 
<xs : element name=" subscription" > 
<xs : complexType> 
<xs : sequence> 

<xs : element ref ="requestedData"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs : element name= " requestedData " > 
<xs : complexType> 
<xs : sequence> 

<xs:element ref ="originalEntity" minOccurs="0"/> 
</xs : sequence> 

<xs :attribute name="objectClass" type="xs : string"/> 
<xs :attribute name="DN" type="xs : string"/> 

<xs : attribute name="notif icationCondition" type="notif icationConditionType" 
use= " opt ional " / > 

<xs :attribute name="expiryTime" type="timeType" use="optional"/> 
<xs : attribute name= " typeOf Subscript ion " type= " typeOf Subscript ionType " / > 
<xs : attribute name=" typeOf Notification" type=" typeOf NotificationType"/> 
</xs : complexType> 
</xs : element> 

<xs : element name= "originalEntity" > 
<xs : complexType> 
<xs : sequence> 

<xs:element ref ="attribute"/> 
</xs : sequence > 

<xs :attribute name="objectClass" type="xs : string"/> 
<xs :attribute name="DN" type="xs : string"/> 
</xs : complexType> 
</xs : element> 

<xs:element name="attribute"> 
<xs : complexType> 
<xs : sequence> 

<xs: element name="value" type="xs : string"/> 
</xs : sequence> 

<xs :attribute name="name" type="xs : string" use="required"/> 
</xs : complexType> 
</xs : element> 

<xs : simpleType name="notif icationConditionType" > 
<xs : restriction base="xs : string" > 
<xs : enumeration value="add"/> 
<xs : enumeration value= "modify" /> 
<xs : enumeration value= "delete "/> 
</xs : restriction> 
</xs : simpleType> 
<xs : simpleType name=" timeType" > 

<xs: restriction base="xs: string "/> 
</xs : simpleType> 

<xs : simpleType name=" typeOf Subs crip t ionType " > 
<xs : restriction base="xs : string" > 

<xs : enumeration value="subscribe"/> 
<xs : enumeration value="unsubscribe"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="typeOfNotif icat ionType "> 
<xs : restriction base="xs : string" > 

<xs : enumeration value="notifyAnyFE"/> 
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<xs : enumeration value="notifySubscribingFE"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 



A.2 XML schema for Subscribe Response 



The SOAP message envelope body shall be empty. 



A.3 XML schema for Notify Request 



<?xml version="1.0" encoding="UTF-8 "?> 

<xs : schema xmlns="http : //www. 3gpp . org/notif ication" 

xmlns :xs="http: //www.w3 . org/2 1/XMLSchema" 
targetNamespace= "http : //www . 3gpp . org/udc/notif ication" 
elementFormDefault=" qualified" > 

<xs : element name= "notification" > 
<xs : complexType> 
<xs : sequence> 

<xs:element ref="object" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs: element name="object " > 
<xs : complexType> 
<xs : sequence> 

<xs:element ref ="attribute" minOccurs="0 " maxOccurs= "unbounded" /> 
</xs : sequence > 

<xs :attribute name="objectClass" type="xs : string"/> 
<xs :attribute name="DN" type="xs : string"/> 

<xs :attribute name="operation" type="operationType" use="required"/> 
</xs : complexType> 
</xs : element> 

<xs : simpleType name="operationType" > 
<xs : restriction base="xs : string" > 
<xs : enumeration value="add"/> 
<xs : enumeration value= "modify" /> 
<xs : enumeration value= "delete "/> 
</xs : restriction> 
</xs : simpleType> 

<xs: element name=" attribute "> 
<xs : complexType> 
<xs : choice> 

<xs:element name="currentValue" type="xs : string" minOccurs="0" 

maxOccurs= "unbounded" /> 
<xs : sequence> 

<xs:element name="bef oreValue" type="xs : string" minOccurs="0" 

maxOccur s= " unbounded " / > 
<xs:element name="af terValue" type="xs : string" minOccurs="0 " 
maxOc cur s = " unbounded " / > 
</xs : sequence> 
</xs : choice> 

<xs :attribute name="name" type="xs : string" use="required"/> 
<xs : attribute name="modif ication" type="modif icationType" use="required"/> 
</xs : complexType> 
</xs : element> 

<xs : simpleType name= " modi f icationType "> 
<xs : restriction base="xs : string" > 
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<xs : enumeration value="add"/> 
<xs : enumeration value="replace"/> 
<xs : enumeration value= "delete "/> 
<xs : enumeration value="none"/> 
</xs : restriction> 
</xs : simpleType> 

</xs : schema> 



A.4 XML schema for Notify Response 

The SOAP message envelope body shall be empty. 
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Annex B (informative): LDAP IVIessage flows and 
Transaction flows for UDC 

B.1 General LDAP Message flows for UDC 
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Figure B.1-1. General LDAP Message flows 

Figure B.1-1 illustrates the general LDAP message flows associated to a LDAP session for UDC, in compliance with 
IETF RFC 45 11 [8]. 



B.2 LDAP Transaction flows for UDC 



Figure B.2-1 illustrates the LDAP transaction flows for UDC. The procedures described in "LDAP Transactions <draft- 
zeilenga-ldap-txn-15.txt>" [5] shall apply. 
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Figure B.2-1. LDAP Transaction flows 

1 . When an FE needs to bind more than one operation to the UDR in one FE session, the FE may issue a Start 
Transaction Request to UDR to begin a transaction. 

2. When receiving a Start Transaction Request, the UDR shall check whether the transaction is allowed, e.g. check 
whether the number of the concurrent transaction exceeds the limit. If the transaction is allowed, the UDR shall 
return a Start Transaction Response with an identity of the transaction assigned by the UDR to the FE and store 
the transaction identity temporarily until the transaction ends or expires. Otherwise, a Start Transaction Response 
with the failure code should be returned. 

3-4.If the result code indicates failure, the following steps shall be skipped and the procedure terminates. Otherwise, 
the FE issues the operations to the UDR with the transaction identity received in the Start Transaction Response 
message from the UDR. The operations with the same transaction identity are in the same transaction. 

5. After all or some of the operations are performed, the FE shall send an End Transaction Request with the 
transaction identity to the UDR to commit or rollback the transaction according to the application logic of the 
FE. 

6. When commitment is indicated in the End Transaction Request, the UDR commits all the updates made. If all 
the updates are committed successfully, a success response is indicated in the End Transaction Response. 
Otherwise, all the updates are rolled back and the data remains as it was before the transaction and failure is 
indicated in the End Transaction Response. When rollback is indicated in the End Transaction Request, the UDR 
cancels all the updates made and return the End Transaction Response with the cancel result to the FE. 



£75/ 



3GPP TS 29.335 version 9.0.0 Release 9 17 



ETSI TS 129 335 V9.0.0 (2010-04) 



Annex C (informative): Change history 






Change history 




Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 




2010-03 


CP#47 


CP-1 00052 






3GPP TS presented for information and approval. 


1.0.0 


9.0.0 





£75/ 



3GPP TS 29.335 version 9.0.0 Release 9 



18 



ETSI TS 129 335 V9.0.0 (2010-04) 



History 



Document history 


V9.0.0 


April 2010 


Publication 



























£75/ 



